1. Technical Field
The present invention relates to a data processing system. In particular, the present invention relates to enhancing software catalog manageability for provisioning applications. Still more particularly, the present invention relates to enhancing manageability of a software catalog, abstracting software configuration, and desired state management.
2. Description of Related Art
Currently, data center administrators have to organize, install, and configure a large number of software products in a data center. These software products have different variations, for example, different locale, different operating system specificity, etc. Some of the variations may or may not be relevant. The relevancy is often handled at the time of installation by administrators. In addition, there may be common attributes across these software products that are replicated for each application definition.
Since the configurations of these software products are complex, it is difficult to achieve a desired outcome of an installation with the proper configuration without post-installation adjustments. The more complex a software product is, the harder it is to coherently specify all configuration parameters for the required elements to be created at installation time.
To alleviate the complexity of software products, response files are used. A response file comprises responses of an installation much like a wizard used during installation, except that the response file is predefined by an administrator with configuration settings of the software product. Thus, a response file comprises a list of name-value pairs that are predefined before installation. While the response file is useful in automatic deployment of software, it is limiting in that the response file is textual and it lacks the flexibility for change. In addition, the response file fails to capture everything a software product needs during post installation configuration.
Furthermore, the response file fails to handle dependencies between configuration settings. For example, a J2EE Web module running on a Web server on machine X may depend on a database module running on a database server on machine Y. Currently, the user has to define the IP address of the database server in which the database module resides at installation time in order to invoke the module.
For complex software, such as, for example, DB2®, multiple instances may need to be created with one instance as a default installation. Each instance running on the same machine may have its own configuration parameters. With response files, these configuration parameters are specified after the software is installed. Post-installation adjustments are time consuming and error prone. Thus, with the above limitations, an automated solution without the use of response files is desired.
Once the software products are installed, the state of a machine is mostly monitored using a manual inventory process. This manual process requires significant time and effort by the Administrators. A need exists for a mechanism that automatically accesses the state of a machine and determines compliance of the machine's current state with a desired state. In addition, in cases of non-compliance, a need exists for a mechanism that automatically applies approved patches to the machine.
Therefore, it would be advantageous to have a mechanism that eases catalog management and provides a flexible mechanism that abstracts software configurations for automation. Furthermore, it would be advantageous to have a mechanism that automatically manages compliance of machines to a desired state.